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Appl. No. 09/809,444 

Reply to Office Action of January 24, 2006 

REMARKS/ARGUMENTS 

Reconsideration of the rejections set forth in the Office Action dated Januaiy 24 7 2006 is 
respectfully requested. Claims 1-30 are currently pending and have been rejected. 

Rejections under 35 U.S.C. S 103 

Claims 1-3, 7-18, and 22-30 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent No. 5,640,394 issued to Schrier et ah (hereinafter "Schrier") in 
view of U.S. Patent No. 6.009,274 issued to Fletcher, et al. (hereinafter "Fletcher"). Claims 4-6 
and 19-21 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over Schrier in 
view of Fletcher and in further view of U.S. Patent No. 6,032,154 issued to Coleman et al. 
(hereinafter "Coleman''). 

L Independent Claims 7, JO, 12, and their respective dependents 

Independent claim 1 recites a method which includes receiving a message to load a first 
protocol stack, and determining whether the first protocol stack can be loaded. If the first 
protocol stack cannot be initially loaded, then the second protocol stack is unloaded. After the 
second protocol stack is unloaded* the first protocol stack is loaded. The second protocol stack is 
selected from a plurality of protocol stacks that does not include the first protocol stack. 

By way of background, Schrier is generally directed to methods of operating two protocol 
stacks thai implement the same protocol. Schrier discloses that the same protocol is 
implemented in one protocol stack in real mode for MS : DOS and in another protocol stack for 
protected mode of WINDOWS (Schrier, column 3 at lines 57-63). Schrier further discloses that 
a stack manager is unable to differentiate which protocol stack to use (Schrier, column 4 at lines 
29-34). Both protocol stacks of Schrier are loaded, otherwise there would be no issue with 
two protocol stacks that implement the same protocol. Hence, Schrier teaches that a first 
protocol s tack and a second protocol stack are such that both can be loaded at the same time . 
The stack manager of Schrier is not able to differentiate between two loaded protocol stacks, and, 
therefore, must transfer communications responsibilities for applications onto a single loaded 
protocol stack. 
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There is no teaching or suggestion in Schrier of determining whether a protocol stack can 
be loaded, as both protocol stacks taught by Schrier are loaded. The issues addressed by Schrier 
pertain to switching from a real mode of operation (which uses a real mode protocol stack) to a 
protected mode of operation (which uses a protected mode protocol stack). 

Contrary to the Examiner's assertions, it is respectfully submitted that Schrier does not 
teach of recei ving a message to load a first protocol stack, and also does not teach determining 
whether the first protocol stack can be loaded. The Examiner has cited lines 29-34 of column 4 
of Schrier as teaching of these limitations. The passage cited by the Examiner reads as follows: 

"As discussed above, once a real mode protocol stack has been loaded and is operating, it 
is not possible to run a subsequent protected mode version of a protocol stack which implements 
the same protocol because the stack manager is not able to differentiate between the two protocol 

stacks." 

At best, this passage teaches that when a real mode protocol stack is loaded and 
running, it is not possible to run another protocol stack that implements the same protocol. 

Both protocol stacks* as discussed above, in Schrier are loaded . There is no teaching or 
indication of receiving a message to load a first protocol stack, in this passage or anywhere else 
in Schrier* Further, although the Examiner also argues that Schrier teaches of determining 
whether a first protocol stack can be loaded, the Applicant disagrees. It is respectfully submitted 
that Schrier discloses only that if one protocol stack is loaded and operating, it is not possible to 
run another protocol stack that implements the same protocol. There is no teaching or suggestion 
that a determination is made as to whether the real mode protocol stack or the protected mode 
version of a protocol stack may be loaded. Fletcher does not overcome these deficiencies of 
Schrier. Therefore, claim 1 is believed to be allowable over Schrier in view of Fletcher for at 
least these reasons. 

The Examiner also argues that Schrier teaches of unloading a second protocol stack if a 
first protocol stack cannot be initially loaded. The Applicant submits that Schrier does not teach 
of determining whether a first protocol stack can be loaded, and therefore does not teach of 
unloading a second protocol stack if the first protocol stack cannot be initially loaded. Further, 
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there is no suggestion in Schrier that terminating a protocol stack is equivalent to unloading the 
protocol stack. The passage cited by the Examiner at lines 34-37 of column 4 of Schrier reads as 
follows: 

U A solution would be to terminate the real mode protocol stack and transfer 
communication responsibilities of the applications using the real mode protocol stack to the 
protected mode protocol stack." 

Transferring communication responsibilities from one loaded protocol stack to another 
loaded protocol stack does not reasonably suggest unloading one loaded protocol stack when an 
unloaded protocol stack cannot be initially loaded. As Fletcher does not overcome this 
deficiency of Schrier, claim 1 is also believed to be allowable for this additional reason. 

On page 3 of the Office Action dated January 24, 2006, the Examiner has explicitly 
admitted that Schrier does not teach selecting a second protocol stack to be unloaded from a 
plurality of protocol stacks that does not include a first protocol stack. However, the Examiner 
argues that Fletcher teaches of such a limitation. The Examiner cites two passages of Fletcher as 
teaching this limitation. The first passage, located at lines 56-61 of column 5 of Fletcher reads a$ 
follows: 

*\ . .generating a server request, wherein said server request identifies the newest version 
level of a software component; generating an agent update request if the agent needs said 
newest version level of said software component; and updating the agent with said newest 
version level of said software component in response to said update request." 

The second passage, located at lines 40-50 of column 13 of Fletcher reads as follows: 

"... system configuration managers and service managers are used to dynamically update 
NIC drivers. . . The system configuration manager. . . can be used to temporarily unload 
the NIC driver and unbind the protocols currently bound to it. The system 
configuration manager then reloads the NIC driver, which is the new version, and notifies 
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the different protocols installed on the system to rebind to the NIC driver...." 
[emphasis added] 

While Fletcher appears to disclose updating an agent in the first passage, Fletcher does 
not appear to teach of unloading any agent or protocol stack selected from a plurality of agents or 
protocol stacks. At best, Fletcher discloses unloading an NIC driver . At lines 50-67 of column 
2, Fletcher discloses an NIC driver as layer 2 software that provides a standardized interface 
between layer 2 and layer 3. At lines 1-7 of column 3, Fletcher discloses that when an ES begins 
building a stack of network protocol software, the NIC driver loads first and is more robust than 
other network protocol software modules. Hence, it is respectfully submitted that a NIC driver is 
apt a protocol stack, but is a proto col module that mav be loaded into a single stack of network 
protocol software. Unloading a NIC driver appears to mean removing the NIC driver itself from 
a stack. 

Fletcher does not teach of or even reasonably suggest selecting a second protocol stack to 
be unloaded from a plurality of protocol stacks that does not include a first protocol stack. 
Instead, Fletcher discloses unloading a NIC driver from a stack, and unbinding protocols bound 
to the NIC driver. It appears that different protocols may be bound to the NIC driver, but there is 
no indication of a plurality of protocol stacks. Unbinding different protocols (which appear to be 
disclosed by Fletcher as being network protocol software modules and not stacks) that arc bound 
to a NIC driver is not equivalent to selecting a second protocol stack to be unloaded from a 
plurality of protocol stacks. The stack from which the NIC driver is unloaded is not a second 
protocol stack selected from a plurality of protocol Stacks that does not include a first protocol 
stack. There is no teaching or suggestion that this stack is a protocol stack that is in any way 
selected from a plurality of protocol stacks. Therefore, claim 1 is believed to be allowable over 
the cited art for at least this additional reason as well. 

Claims 2-9, 29, and 30 each depend either directly or indirectly from claim 1 and arc, 
therefore, each believed to be allowable over the cited art for at least the reasons set forth with 
respect to claim 1 . Each of these dependent claims recites additional limitations which, when 
considered in light of claim 1 , are believed to further distinguish the claimed invention over cited 
art. By way of example, claim 29 recites that selecting a second protocol stack from a plurality 
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of protocol stacks includes at least one of determining when the second protocol stack is in use, 
determining an amount of memory the second protocol stack needs to be loaded, and determining 
whether the second protocol stack is compatible with the first protocol stack. On page 6 of the 
Office Action Dated January 24, 2005, the Examiner has acknowledged that Scbxier fails to teach 
the limitations of claim 29, but has argued that Fletcher teaches of determining whether a second 
protocol stack is in use and determining whether the second protocol stack is compatible with a 
first protocol stack. It is noted that the Examiner has not addressed the limitation of determining 
an amount of memory the second protocol stack needs to be loaded except to indicate that 
Schrier does not teach this limitation. In his rejection, the Examiner cites the same passage of 
Fletcher that was cited above. This passage discloses that a system configuration manager can be 
used to temporarily unload an NIC driver and unbind the protocols currently bound to it> and that 
the system configuration manager can reloads the NIC driver and notify the different protocols 
in$talled on the system to rebind to the NIC driver. It is not clear to the Applicant how this 
passage teaches of determining whether a second protocol stack is in use, or whether the second 
protocol stack is compatible with a first protocol stack. Fletcher does not appear to disclose 
either of these limitations, or the limitation of determining an amount of memory the second 
protocol stack needs to be loaded Therefore, claim 29 is believed to be allowable over the cited 
art for at least this reason. 

Independent claims 10 and 1 2 recite similar limitations as recited in amended claim 1 . 
Therefore, claims 10, 12, and their dependents are each believed to be allowable over the cited 
art for at least the reasons set forth above with respect to claim 1 > 

2 Independent Claims 14, 25, 27, and their respective dependents 

Independent claim 14 recites a method which includes sending a message from a first 
node to a second node to load a first protocol stack. The method also includes the second node 
receiving the message to load the first protocol stack, the second node determining whether the 
first protocol stack can be loaded, the second node selecting a second protocol stack from a 
plurality of protocol stacks, and the second node unloading a second protocol stack if the first 
protocol stack cannot be initially loaded on the second node. Finally, the method includes the 
second node loading the first protocol stack. 
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Claim 14 includes some similar limitations as recited in claim 1. As such, claim 14 is 
believed to be allowable over Schrier in view of Fletcher for at least the reasons set forth above 
with respect to claim 1 . 

The Examiner stated on page 5 of the Office Action dated August 8, 2005 that claim 14 is 
a variation of claim 1 , and has reiterated this statement in the Office Action dated January 24, 
2006. As noted by the Applicant in Amendment D, although the Examiner has broadly stated 
that the combination of cited art teaches or suggests all limitations corresponding to the claimed 
method, claim 14 recites limitations which are not included in claim 1 and are also neither 
taught nor suggested by the cited art. For example, claim 14 recites that a first node sends a 
message to a second node to load a first protocol stack. The Examiner has not addressed this 
limitation, but the Applicant respectfully submits that there is no teaching in the cited art of first 
and second nodes, let alone a first node that sends a message to a second node to load a first 
protocol stack. The Examiner has not addressed the limitation of a first node sending a message 
to a second node to load a first protocol stack. The Applicant would gteatly appreciate it if the 
Examiner would provide details on how he believes the cited art suggests such a limitation, so 
that the Applicant can properly address the rejections of claim 14 . As neither Schrier nor 
Fletcher, alone or in combination, appears to teach or reasonably suggest the limitation of a first 
node sending a message to a second node (e.g., a message to load a first protocol stack), claim 14 
is believed to be allowable over the cited for at least this reason as welL 

Claims 15-24 each depend either directly or indirectly from independent claim 14 and, 
hence, are each believed to be allowable over the cited art for at least the reasons set forth above 
with respect to claim 14. Each of these dependent claims recites additional limitations which, 
when considered in light of the limitations in claim 14, are believed to further distinguish the 
claimed invention over the art of record By way of example, claim 24 recites that a message 
sent from a first node to a second node specifies portions of a first protocol stack that are to be 
loaded on a second node. The Examiner indicates on page 5 of the Office Action dated January 
24, 2006 that claim 24 constitutes a variation of the method previously rejected in the present 
office action, and that the combination of cited prior art teaches or suggests all the limitations 
corresponding to the claimed method However, the Applicants respectfully submit that the 
Examiner has not shown how a combination of the cited art teaches or suggests that a message 
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sent from a.first node to a second node specifics portions of a first protocol stack that are to be 
loaded on the second node . The Applicant submits that there is no teaching or suggestion in 
Schrier or Fletcher that a message sent from a first node to a second_node specifies portions of a 
first protocol stack that are to be loaded on the second node . Therefore, claim 24 is believed to 
be allowable for at least this additional reason. 

Claims 25 and 27 recite similar limitations as recited in amended claim 14. Therefore, 
claims 25, 27, and their dependents are all believed to be allowable over the cited art for at least 
the reasons set forth above with respect to claim 14. 



For at least the foregoing reasons, the Applicant believes all the pending claims are in 
condition for allowance and should be passed to issue. If the Examiner feels that a telephone 
conference would in any way expedite the prosecution of the application, please do not hesitate 
to call the undersigned at (650) 694-5339. 



Conclusion 




Respectfully submitted. 
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